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Intent-Driven Functional Verification of Digital Designs 



[0001] This is a divisional of US Patent Application No. 09/566,684, filed on May 8, 2000, 

now issued as US Patent No. 6,651,228, which is hereby incorporated by reference in its entirety. 

COPYRIGHT NOTICE 

[0002] Contained herein is material that is subject to copyright protection. The copyright 

owner has no objection to the facsimile reproduction of the patent disclosure by any person as it 
appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights 
to the copyright whatsoever. 

BACKGROUND 

Field 

[0003] Embodiments of the present invention relate generally to the field of design 

verification. More particularly, embodiments of the present invention relates to a new approach for 
functional verification of digital designs. 

Description of the Related Art 

[0004] The objective of design verification is to ensure that errors are absent from a design. 

Deep sub-micron integrated circuit (IC) manufacturing technology is enabling IC designers to put 
millions of transistors on a single IC. Following Moore's law, design complexity is doubling every 
12-18 months, which causes design verification complexity to increase at an exponential rate. In 
addition, competitive pressures are putting increased demands on reducing time to market. The 
combination of these forces has caused an ever worsening 'Verification crisis". 
[0005] Today's design flow starts with a specification for the design. The designer then 

implements the design in a language model, typically Hardware Description Language (HDL). This 

Docket No.: 59165-298553 

Express Mail No.: EL 971 1 97827 US - 1 - 



model is typically verified to discover incorrect input/output (I/O) behavior via a stimulus in 
expected results out paradigm at the top level of the design. 

[0006] By far the most popular method of functional verification today, simulation-based 

functional verification, is widely used within the digital design industry as a method for finding 
defects within designs. A very wide variety of products are available in the market to support 
simulation-based verification methodologies. However, a fundamental problem with conventional 
simulation-based verification approaches is that they are vector and testbench limited. 
[0007] Simulation-based verification is driven by a testbench that explicitly generates the 

vectors to achieve stimulus coverage and also implements the checking mechanism. Testbenches 
create a fundamental bottleneck in simulation-based functional verification. In order to verify a 
design hierarchy level, a testbench must be generated for it. This creates verification overhead for 
coding and debugging the testbench. Hence, a significant amount of expensive design and 
verification engineering resources are needed to produce results in a cumbersome and slow process. 
[0008] Several methods have been attempted by Electronic Design Automation (EDA) 

companies today in order to address the shortcomings of simulation. However, none of these 
attempts address this fundamental limitation of the process. For example, simulation vendors have 
tried to meet the simulation throughput challenge by increasing the performance of hardware and 
software simulators thereby allowing designers to process a greater number of vectors in the same 
amount of simulation time. While this does increase stimulus coverage, the results are incremental. 
The technology is not keeping pace with the required growth rate and the verification processes are 
lagging in achieving the required stimulus coverage. 

[0009] Formal verification is another class of tools that has entered the functional 

verification arena. These tools rely on mathematical analysis rather than simulation of the design. 
The strong selling point of formal verification is the fact that the results hold true for all possible 
input combinations to the design. However, in practice this high level of stimulus coverage has 
come at the cost of both error coverage and particularly usability. While some formal techniques are 
available, they are not widely used because they typically require the designer to know the details of 
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how the tool works in order to operate it. Formal verification tools generally fall into two classes: 
(1) equivalence checking, and (2) model checking. 

[0010] Equivalence checking is a form of formal verification that provides designers with the 

ability to perform RTL-to-gate and gate-to-gate comparisons of a design to determine if they are 
functionally equivalent. Importantly, however, equivalence checking is not a method of functional 
verification. Rather, equivalence checking merely provides an alternate solution for comparing a 
design representation to an original golden reference. It does not verify the functionality of the 
original golden reference for the design. Consequently, the original golden reference must be 
functionally verified using other methods. 

[0011] Model checking is a functional verification technology that requires designers to 

formulate properties about the design's expected behavior. Each property is then checked against an 
exhaustive set of functional behaviors in the design. The limitation of this approach is that the 
designer is responsible for exactly specifying the set of properties to be verified. The property 
specification languages are new and obscure. Usually the technology runs into capacity problems 
and the designer has to engage with the tools to solve the problems. There are severe limits on the 
size of the design and the scope of problems that can be analyzed. For example, the designer does 
not know which properties are necessary for complete analysis of the design. Further, specifying a 
large number of properties does not correlate well with better error coverage. Consequently, model 
checking has proven to be very difficult to use and has not provided much value in the verification 
process. 

[0012] In view of the foregoing it would be desirable to create a verification methodology to 

create high quality designs without the need for simulation testbench and to increase the 
productiveness of design engineers. 
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SUMMARY 

[0013] Methods and apparatus are described for facilitating analysis of the intended behavior 

of a hardware design. According to one embodiment of the present invention, a language-based 
representation of a hardware design is received. Multiple design verification checks are generated 
for use in connection with model checking by applying a set of one or more predetermined 
properties to the language-based representation of the hardware design. Then, the hardware design, 
as implemented according to the language-based representation, is verified against intended 
behavior, represented by the set of one or more predetermined properties, by determining whether 
one or more of the design verification checks are violated by the hardware design. Finally, results of 
the verification may be reported. 

[0014] Other features of the present invention will be apparent from the accompanying 

drawings and from the detailed description that follows. 
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BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 

[0015] Embodiments of the present invention are illustrated by way of example, and not by 

way of limitation, in the figures of the accompanying drawings and in which like reference numerals 
refer to similar elements and in which: 

[0016] Figure 1 is a block diagram illustrating an exemplary architecture of an Intent-Driven 

Verification system according to one embodiment of the present invention. 
[0017] Figure 2 is a high-level flow diagram illustrating an Intent-Driven Verification 

processing according to one embodiment of the present invention. 

[0018] Figure 3 is an example of a computer system upon which one embodiment of the 

present invention may be implemented. 

[0019] Figure 4A is a high-level block diagram illustrating an exemplary Sentry verification 

entity according to one embodiment. 

[0020] Figure 4B is a schematic diagram illustrating an exemplary implementation of a 

Sentry verification entity according to one embodiment. 

[0021] Figure 4C illustrates what is meant by concept of flow of logical signals according to 

one embodiment of the present invention. 

[0022] Figure 5 is a flow diagram that illustrates the automatic formulation of design 

verification checks according to one embodiment of the present invention. 

[0023] Figure 6A is a block diagram illustrating a design example. 

[0024] Figure 6B is a block diagram illustrating the design example of Figure 6A with the 

inclusion of Sentry verification entities. 

[0025] Figure 7 is a state diagram illustrating the operation of the bus interface units of 

Figures 6A and 6B. 

[0026] Figure 8 is a simplified state diagram illustrating the operation of the round robin 

arbiter of Figures 6A and 6B. 
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[0027] Figures 9A - 9E represent an exemplary RTL source code representation of the 

design example of Figure 6B. 

[0028] Figure 10 is a block diagram that conceptually illustrates linking processing 

according to one embodiment of the present invention. 

[0029] Figure 11 is a high-level flow diagram that illustrates linking processing according to 

one embodiment of the present invention. 

[0030] Figure 12 is a flow diagram that illustrates processing block 1 130 of Figure 11 

according to one embodiment of the present invention. 

[0031] Figures 13 A - 13E illustrate an exemplary text report file for the annotated RTL of 

Figures 9A - 9E according to one embodiment of the present invention. 
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DETAILED DESCRIPTION 
[0032] Methods and apparatus are described for facilitating analysis of the intended behavior 

of a hardware design. Embodiments of the present invention seek to solve or at least alleviate the 
above-referenced problems of conventional verification approaches by employing a revolutionary 
approach for functional verification. According to one embodiment, an functional verification 
approach enables verification of design intent prior to simulation and synthesis. Identifying and 
eliminating design defects early in the design cycle eliminates costly down-stream design iterations 
resulting in dramatically shorter design verification cycles. 

[0033] Broadly stated, embodiments of the present invention allow errors in a hardware 

design to be discovered by checking a representation of the hardware design against design intent. 
In one embodiment, a comprehensive set of design verification checks including behavioral integrity 
checks and temporal integrity checks are automatically generated based upon a language 
representation of a hardware design and information regarding the design intent, such as, the 
intended behavior, or the intended flow of logical signals among a plurality of variables in the 
language representation of the hardware design. The design intent may be communicated to a 
hardware design verification tool, for example, by way of inline annotations embedded within the 
hardware design description. 

[0034] According to one embodiment, a novel "verification entity," referred to as a Sentry™ 

verification entity, is provided that facilitates modeling and verification of what the designer 
intended to build (SENTRY is a trademark or registered trademark of Real Intent, Inc. of Santa 
Clara, California). For example, feedback may be provided to the designer regarding differences 
between what has actually been created by a language representation of a hardware design, such as a 
Register Transfer Language (RTL) source code representation, and the design intent, e.g., the 
intended flow of logical signals in a the hardware design. 

[0035] Briefly, Sentry verification entities may conceptually be thought of as objects, which 

are embedded in a design during the verification process. Sentry verification entities are not 
structural entities - they are not included in the final hardware. Rather, Sentry verification entities 
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are special purpose objects for support of verification. Sentry verification entities provide a 
mechanism for expressing design intent. Expressed design intent (i.e., design intent that is explicitly 
stated by the designer) and implied design intent (i.e., expected behaviors that should occur within 
standard design practices although not explicitly stated by the designer) are checked against what the 
design actually accomplishes. As will be described further below, in one embodiment, Sentry 
verification entities are embedded within a model of the design under test to represent sentinel 
variables in the design through which logical signals in the design pass. For example, a Sentry 
verification entity may be used to explicitly associate state information with a sentinel variable 
independent of the value of the sentinel variable. The state information may indicate whether or not 
the sentinel variable is active or inactive at various points in the control flow structure of a finite 
state machine associated with the hardware design representation. Consequently, the integrity of the 
data flow can be verified by confirming checks that are expressed as a function of the states 
associated with one or more sentinel variables. 

[0036] According to another embodiment, a comprehensive set of design verification checks 

may be formulated by applying predetermined properties to an annotated hardware design 
representation. The application of predetermined properties, such as conflicting assignments (CA), 
block enable (BE), assignment execution (AX), constant value memory element (CME), constant 
value variable (CV), Sentry activate always off (AAO), loss of valid data (LVD), assertion 
correctness (AC), and access of invalid data (AID), to signal propagation among all the sentinel 
variables results in an exhaustive list of checks that confirm whether or not the predetermined 
properties hold true for the intended flow of logical signals. Advantageously, in this manner, a 
designer gets the benefits of a comprehensive Intent-Driven Verification™ (IDV™) methodology by 
simply identifying sentinel variables and providing information regarding intended temporal 
behaviors and/or relationships (INTENT-DRIVEN VERIFICATION and IDV are trademarks or 
registered trademarks of Real Intent, Inc. of Santa Clara, California.) 
[0037] According to yet another embodiment, an ordered representation of the 

comprehensive set of design verification checks can be created to allow conclusions to be drawn 
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about the hardware design. For example, dependency relationships among the comprehensive set of 
design verification checks may be determined. A check is dependent upon a set of other checks if it 
is impossible to violate the first without violating at least one or more checks from the set. After the 
dependency relationships have been determined, this linking information may be used to facilitate 
error reporting or to streamline check processing. Notably, reporting of multiple intent violations 
due to a common design defect may be avoided thereby containing redundant failures commonly 
produced by prior art simulators. Additionally, if there is no way to violate the current check being 
verified without also violating one or more other previously processed checks, there is no point in 
reporting the violation of the current check since this would not communicate any new information 
to the user. Finally, assuming it has already been determined that a first check cannot be violated, 
during the processing of a subsequent check, if the current search path violates the first check, then 
the current search path can be abandoned since there is no solution along the current search path. In 
this manner, checks may be more efficiently processed and the user is not inundated with redundant, 
cumulative information. 

[0038] In the following description, for the purposes of explanation, numerous specific 

details are set forth in order to provide a thorough understanding of the present invention. It will be 
apparent, however, to one skilled in the art that the present invention may be practiced without some 
of these specific details. In other instances, well-known structures and devices are shown in block 
diagram form. 

[0039] Embodiments of the present invention include various steps, which will be described 

below. The steps may be performed by hardware components or may be embodied in machine- 
executable instructions, which may be used to cause a general-purpose or special-purpose processor 
programmed with the instructions to perform the steps. Alternatively, the steps may be performed 
by a combination of hardware and software. 

[0040] Embodiments of the present invention may be provided as a computer program 

product that may include a machine-readable medium having stored thereon instructions, which may 
be used to program a computer (or other electronic devices) to perform a process according to the 
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present invention. The machine-readable medium may include, but is not limited to, floppy 
diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, 
EEPROMs, magnet or optical cards, flash memory, or other type of media / machine-readable 
medium suitable for storing electronic instructions. Moreover, the present invention may also be 
downloaded as a computer program product, wherein the program may be transferred from a remote 
computer to a requesting computer by way of data signals embodied in a carrier wave or other 
propagation medium via a communication link (e.g., a modem or network connection). 
[0041] For convenience, embodiments of the present invention will be described with 

reference to Verilog and VHDL. However, the present invention is not limited to any particular 
representation of a hardware design. For example, the language representation of a hardware design 
may be in the C programming language, C++, derivatives of C and/or C++, or other high-level 
languages. In addition, while embodiments of the present invention are described with reference to 
functional verification of hardware designs, aspects of the present invention are equally applicable to 
other types of design activities as well, such as hardware synthesis, design optimization, design 
simulation and performance analysis. Furthermore, while embodiments of the present invention are 
described with reference to the provision of augmented design information by way of hardware 
description language (HDL) annotations, it is contemplated that the augmented design information 
could reside in a file separate from the file containing the HDL. Alternatively, semantics capable of 
capturing augmented design information, e.g., intended behavior, may be incorporated within a 
HDL. 

Terminology 

[0042] Brief definitions of terms are given below. 

[0043] A "design" generally refers to a description of a collection of objects, such as 

modules, blocks, wires, registers, etc. that represent a logic circuit. A design may be expressed in 
the form of a language. For example, a hardware description language (HDL), such as Verilog or 
VHDL can be used to describe the behavior of hardware as well as its implementation. 
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[0044] An "annotation" generally refers to text embedded in a language construct, such as a 

comment statement or remark. Most programming languages have a syntax for creating comments 
thereby allowing tools designed to read and/or process the programming language to read and ignore 
the comments. 

[0045] "Simulation' 5 generally refers to the process of evaluating design behavior for a set of 

input conditions to draw approximate conclusions about the behavior of many different attributes of 
the design. 

[0046] "Formal analysis" generally refers to the process of analyzing a design for all possible 

input conditions to derive definite conclusions about the behavior of an attribute with respect to the 
design. 

[0047] "Functional verification" generally refers to the process of applying stimuli to a 

design under test with appropriate checking mechanisms to either detect a defect in the design or to 
establish that the functionality performs as expected. Typically, the three key components of a 
functional verification process are the applied stimulus, the checking mechanism, and the user's 
ability to both run the process and debug the results. As will be described later, the effectiveness of 
a functional verification process may be measured in terms of the following three metrics: (1) error 
coverage, (2) stimulus coverage, and (3) usability. 

[0048] The term "design intent" generally refers to what the designer intends in terms of the 

interaction between components of the design and the designer's expectations regarding acceptable 
functional behavior. For example, the designer may intend a particular behavior or a particular flow 
of logical signals among the variables of an RTL design description (the intended flow). 
Traditionally, design intent has referred to input constraints, internal constraints, and/or cause and 
effect modeling. In contrast, as used herein the term "design intent" includes "implied design intent" 
and additional forms of "expressed design intent." Expressed design intent generally refers to design 
intent explicitly conveyed by a designer by way of intent modeling semantics in a control file or 
embedded within annotations of RTL source code (the hardware design representation), for example. 
Examples of expressed design intent regarding the intended flow of logical signals may include the 
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intended temporal behaviors (e.g., the ACK signal must go high within 4 cycles of the REQ signal) 
and the intended data flow relationships (e.g., the data being loaded from the input port is the data 
intended for transfer by the driver of the input port). Implied design intent generally refers to design 
intent that is inferred from the design description including expected behaviors that should occur 
within standard design practices. 

[0049] A "Sentry verification entity" or "verification entity" generally refers to an object that 

may be embedded within a hardware design to facilitate the modeling of design intent. As described 
further below, Sentry verification entities provide a mechanism by which state information can be 
associated with variables in a representation of a hardware design. According to various 
embodiments of the present invention, Sentry verification entities may be used to verify a design by 
allowing design intent (both expressed and implied) to be checked against what the design actually 
accomplishes. 

[0050] A "property" generally refers to a condition or statement, typically expressed in terms 

of a relationship among a group of one or more signals in a hardware design, that must hold for the 
hardware design to function as intended. According to one embodiment, violations are reported at 
the property-level rather than at the more detailed level of design verification checks. 
[0051] The term "design verification check" or simply "check" generally refers to a 

mechanism for verifying a property. Properties may be composed of one or more checks, which are 
the atomic units that are verified. That is, properties may be broken down into one or more checks. 
Since properties and checks are sometimes equivalent (i.e., when a property comprises a single 
design verification check), these terms may at times be used interchangeably. Examples of checks 
include, but are not limited to: monitors, Boolean conditions, sensitized path conditions, and the like. 
According to one embodiment, a comprehensive set of checks may be automatically formulated 
based upon a representation of the hardware design and information regarding the intended flow of 
logical signals among a plurality of variables in the representation. 



Docket No.: 59165-298553 
Express Mail No.: EL 971197827 US 



- 12- 



[0052] Check A is said to be "dependent" upon checks B, C, and D if it is impossible to 

violate check A without violating at least one of checks B, C, and D. If check A is dependent upon 
check B, C and D, then a "dependency relationship" exists between check A and checks B, C, and D. 

Characteristics of Effective Functional Verification 

[0053] As mentioned earlier, the effectiveness of a functional verification process may be 

measured in terms of error coverage, stimulus coverage, and usability. Error coverage refers to the 
ability of the verification methodology to identify a broad range of potential design defects. A 
verification process should be effective in identifying all potential failures in a hardware design. 
This is achieved by creating a checking mechanism. In traditional practice, the checking mechanism 
is created by comparing the hardware design representation, e.g., RTL source code, to an 
independently created design model. This independent model is used to predict the response of the 
design for comparison. Given that the purpose of the verification process is to assure design quality, 
it is important to build a very comprehensive checking mechanism. 

[0054] Stimulus coverage refers to the ability of the verification methodology's ability to 

achieve broad coverage of the input domain. Preferably, the verification process should examine all 
possible combinations of input sequences for the design under test. High stimulus coverage is 
critical to verification, particularly with designs containing large numbers of states. Yet, all existing 
technologies fall short here. The ideal verification process should achieve exhaustive stimulus 
coverage for any design. 

[0055] Usability refers to the overall ease and effectiveness of user interaction with the 

verification tool. The verification process should be simple and effective to use. To accomplish 
this, setup costs for running the process should be minimized, and the reported information should 
be well organized to allow easy debugging. The process should fit well into existing design 
methodologies and should require a minimum amount of training in order to be used effectively. 
Usability should be given high priority when developing any functional verification system and 
should not be an afterthought that is secondary to the underlying technology. 
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Intent-Driven Verification Overview 

[00561 Intent-Driven Verification (IDV) is a revolutionary approach for functional 

verification of hardware designs. IDV ranks high on all three of the above-described metrics and 
successfully integrates the technologies required for an effective functional verification system 
together into a complete package. Briefly, IDV identifies the "intent gap" between what a designer 
intends to build (design intent) and what has actually been created within the language representation 
of the hardware design (design implementation), such as RTL source code. By augmenting the RTL 
source code or associated control file with information indicative of the designer's intent, a 
comprehensive set of checks can be automatically formulated and verified. As mentioned above, the 
RTL may also be expanded to include semantics capable of conveying information indicative of the 
designer's intent or desired functional behavior. This provides a novel and effective way to identify 
design problems early in the development process. Additionally, IDV is scalable, provides fast 
isolation of the source of defects, and significantly reduces the overall verification effort, thus 
enabling IC design projects to dramatically reduce their time to market. 

An Exemplary Intent-Driven Verification System 

[0057] Figure 1 is a block diagram illustrating an exemplary architecture of an Intent-Driven 

Verification (IDV) system according to one embodiment of the present invention. According to the 
embodiment depicted, the IDV system 100 includes an annotated hardware design representation 
reader 120. The annotated hardware design representation reader 120 may be a conventional RTL 
reader with the additional ability to recognize and process augmented design information. 
Alternatively, the annotated hardware design representation reader 120 may be a conventional C or 
C++ parser capable of processing the augmented design information. In one embodiment, the 
augmented design information comprises annotations embedded within the hardware design 
representation 105, such as an annotated RTL source code file 105 containing special verification 
semantics (directives). Exemplary directives and their syntax are described further below. In 
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alternative embodiments, the augmented design information may be included in a control file 
associated with the hardware design representation 105, such as control file 1 15. 
[0058] The IDV system 100 also includes a control file reader 130. The control file reader 

130 may be a conventional control file reader. Alternatively, in the case that the augmented design 
information (e.g., information regarding design intent, such as the intended flow of logical signal 
among variables in the hardware design representation) is to be provided by way of control file 115, 
then the control file reader 130 additionally includes parsing functionality enabling the control file 
reader 130 to recognize and process the augmented design information. 

[0059] According to the architecture depicted, the IDV system 100 also includes a model 

builder 145, a design intent analyzer 140, a property manager 165, an analysis engine 180, and a 
report manager 170. The model builder 145 receives output of the hardware design representation 
reader 120, the control file reader 130, and a cell library (not shown) and builds an internal 
representation of the hardware design, a model. Additionally, based upon the designer's expressed 
design intent and/or implied intent, the model builder embeds special verification entities into the 
model for the purpose of identifying the intent gap between what the designer intended to build 
(design intent) and what has actually been created within the source code (design implementation). 
These special embedded objects are referred to as Sentry verification entities. Details regarding the 
use, functionality, and implementation of Sentry verification entities are presented below. 
[0060] The design intent analyzer 140 automatically produces a comprehensive set of design 

verification checks, such as behavioral integrity checks and temporal integrity checks, based upon a 
predetermined set of properties and the Sentry verification entities. For example, for each Sentry 
verification entity in the model, the design intent analyzer 140 may automatically create checks to 
verify that there is no access of invalid data by the Sentry verification entity and that no active data 
from the Sentry verification entity is lost. Other properties and verification of these properties, in 
terms of checks and Sentry verification entities, are discussed below. Consequently, by merely 
associating the Sentry attribute with a variable in an RTL representation of the hardware design and 
providing minimal additional information regarding the desired/expected interaction between 
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components of the design and regarding expectations for acceptable functional behavior, the design 
intent analyzer 140 enables verification while the design is being developed and facilitates detection 
of design defects at the RTL-level. Advantageously, in this manner, the designer is not required to 
manually code individual monitors for each property he/she would like to verify. Rather, 
verification cycle time and resource requirements are reduces by allowing the designer to simply 
associate the Sentry attribute with certain important variables, sentinel variables (e.g., by "declaring" 
the sentinel variables as Sentry verification entities), provide minimal additional information 
regarding the desired/expected interaction between components of the design (such as an indication 
regarding the expected state of the sentinel variables at various points in the control flow structure of 
a finite state machine associated with the hardware design representation), and the generation of a 
complete set of checks involving the sentinel variables is automatically performed. Importantly, the 
use of Sentry verification entities to enable automatic formulation of a comprehensive set of design 
verification checks not only dramatically reduces verification effort and time but also significantly 
increases design robustness. 

[0061] The property manager 1 65 maintains information regarding relationships among the 

checks generated by the design intent analyzer and additionally maintains information regarding 
relationships among properties and whether the properties are satisfied, violated, or whether the 
results are indeterminate or conditional upon one or more other properties. According to one 
embodiment, the property manger 165 and analysis engine 180 cooperate to determine dependency 
relationships among the comprehensive set of design verification checks. As described further 
below, the dependency relationships (or "linking" information) may be used to facilitate error 
reporting or used to streamline check processing. 

[0062] The analysis engine 1 80 verifies the model produced by the model builder by testing 

for violations of the properties. Preferably, the analysis engine 1 80 employs an analysis-based 
technique, such as an integration of simulation and formal analysis methodologies, so as to 
maximize stimulus coverage for the design under test. However, in alternative embodiments, 
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simulation, functional verification, or other well-known verification methodologies may be 
employed individually. 

[00631 The report manager 170 provides feedback to the designer, in the form of a report file 

1 75, for example, regarding potential design defects. It should be noted that a single error in the 
hardware design might lead to a violation of 25 to 30 or more different design verifications checks. 
There is no point in reporting every violation if the user has already been notified that an error exists. 
Therefore, according to one embodiment, an intent violation hierarchy may be maintained when 
reporting design defects. In this manner, redundancy of reported information is contained. Multiple 
intent violations due to a common defect are not reported. This minimizes the amount of data to be 
analyzed to detect defects. 

High-level Intent-Driven Verification Processing 

[0064] Figure 2 is a high-level flow diagram illustrating Intent-Driven Verification 

processing according to one embodiment of the present invention. The Intent-Driven Verification 
process generally breaks down into three fundamental technologies, intent capture, intent gap 
detection, and intent violation reporting. A method for capturing the designer's intent for the design 
(intent capture) is represented by processing blocks 210-230, detection of areas within the design 
source code that differ from the original design intent (intent gap detection) comprises processing 
block 240, and identification and reporting of the space between the designer's intent and the 
design's implementation (intent violation reporting) is represented by processing block 250. Briefly, 
after a complete view of the overall design intent is captured, e.g., after the two forms of intent are 
integrated together by the design intent analyzer 140, the analysis engine 180 may begin identifying 
individual intent violations. When the analysis is complete, the report manager 170 provides 
feedback to the user in a well-organized manner. In one embodiment, the processing blocks 
described below may be performed under the control of a programmed processor, such as processor 
302. However, in alternative embodiments, the processing blocks may be fully or partially 
implemented by any programmable or hardcoded logic, such as Field Programmable Gate Arrays 
(FPGAs), TTL logic, or Application Specific Integrated Circuits (ASICs), for example. 

Docket No.: 59165-298553 

Express Mail No.: EL 971 1 97827 US , - 1 7 - 



[0065] Intent-Driven Verification processing begins at processing block 210 where a 

language representation of a hardware design under test is received. The language representation 
may be RTL source code, such as Verilog or VHDL. Preferably, to take advantage of the control 
flow structure of the language representation, augmented design information is provided by inline 
annotations to the language representation of the hardware design, e.g., annotated RTL 105. 
However, in alternative embodiments, design intent may be provided in the control file 115. 
[0066] In this example, at processing blocks 220 and 230, the design intent is captured in two 

basic forms: expressed and implied. Expressed design intent is design intent that is explicitly stated 
by the designer. The implementation of IDV described herein may use an elegant RTL-based 
method to express this intent in an annotated RTL source code file, such as annotated hardware 
description representation 105, and/or the control file 1 15. Regardless of their source, the expressed 
design intent is determined based upon the annotations. Importantly, the form of intent modeling 
provided herein is very intuitive and does not require the users to learn a new language. 
Additionally, this intent modeling captures the intent in a concise manner and thereby minimizes 
setup effort. Typically, the expressed intent defines the interaction between components of the 
design and/or the designer's expectations regarding acceptable functional behavior. Implied design 
intent may be inferred directly from the design description. Advantageously, implied intent capture 
infers numerous and complex design behaviors automatically without requiring a designer to 
explicitly state them. Typically, this consists of expected behaviors that should occur within 
standard design practices. 

[0067] At processing block 240, the intent gap is identified based upon the design intent and 

the design implementation. In the example depicted, the two forms of design intent are integrated 
and used as input to processing block 240. In alternative embodiments, the intent gap may be 
determined for only a single form of design intent or one or more other combinations of subsets of 
expressed and implied design intent. At any rate, preferably, the intent gap is statically identified 
using functional verification techniques. The intent gap is the distance between a design's intent and 
the actual implementation. According to one embodiment, IDV detects the intent gap in terms of 
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individual intent violations. Intent violations are the result of defects within the design 
implementation. Importantly, because the intended behavior of the design is well understood, intent 
violations isolate design defects with high localization to their source. 

[0068] At processing block 250, feedback is provided to the user. For example, one or more 

report files 175 may be created that provide information regarding the individual intent violations 
identified in processing block 240. Preferably, the redundancy of information is contained and the 
intent violation data is organized into a format that provides useful and highly accurate debugging 
information to a designer. Additionally, sequential debugging information may be provided along 
with detailed explanations of any identified intent violations. An exemplary report file format is 
illustrated in Figures 13A - 13E. 

An Exemplary Computer Architecture 

[0069] Having briefly described an exemplary verification system in which various features 

of the present invention may be employed and high-level Intent-Driven Verification processing, an 
exemplary machine in the form of a computer system 300 representing an exemplary workstation, 
host, or server in which features of the present invention may be implemented will now be described 
with reference to Figure 3. Computer system 300 comprises a bus or other communication means 
301 for communicating information, and a processing means such as processor 302 coupled with bus 
301 for processing information. Computer system 300 further comprises a random access memory 
(RAM) or other dynamic storage device 304 (referred to as main memory), coupled to bus 301 for 
storing information and instructions to be executed by processor 302. Main memory 304 also may 
be used for storing temporary variables or other intermediate information during execution of 
instructions by processor 302. Computer system 300 also comprises a read only memory (ROM) 
and/or other static storage device 306 coupled to bus 301 for storing static information and 
instructions for processor 302. 

[0070] A data storage device 307 such as a magnetic disk or optical disc and its 

corresponding drive may also be coupled to computer system 300 for storing information and 
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instructions. Computer system 300 can also be coupled via bus 301 to a display device 321, such as 
a cathode ray tube (CRT) or Liquid Crystal Display (LCD), for displaying information to an end 
user. For example, graphical and/or textual depictions/indications of design errors, and other data 
types and information may be presented to the end user on the display device 321 . Typically, an 
alphanumeric input device 322, including alphanumeric and other keys, may be coupled to bus 301 
for communicating information and/or command selections to processor 302. Another type of user 
input device is cursor control 323, such as a mouse, a trackball, or cursor direction keys for 
communicating direction information and command selections to processor 302 and for controlling 
cursor movement on display 321 . 

[00711 A communication device 325 is also coupled to bus 301 . Depending upon the 

particular design environment implementation, the communication device 325 may include a 
modem, a network interface card, or other well-known interface devices, such as those used for 
coupling to Ethernet, token ring, or other types of physical attachment for purposes of providing a 
communication link to support a local or wide area network, for example. In any event, in this 
manner, the computer system 300 may be coupled to a number of clients and/or servers via a 
conventional network infrastructure, such as a company's Intranet and/or the Internet, for example. 

Modeling Intended Flow of Logical Signals in a Hardware Design 

[0072] Currently available verification methodologies lack suitable mechanisms to allow 

designers to adequately express their design intent. Rather, existing functional verification 
methodologies, such as model checking, generally require a designer to formulate properties about 
the design's expected behavior. Consequently, the designer is responsible for exactly specifying the 
set of properties to be verified. One problem with this approach, however, is that the designer may 
not know or even be capable of knowing which properties are necessary for a complete analysis of 
the design. Additionally, the property specification languages are new and obscure and typically 
require the designer to know the details of how the verification tool works in order to operate it. 
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[0073] Briefly, the intent modeling techniques described herein seek to raise the level of 

abstraction of the verification process to increase the productiveness of existing design 

environments/design verification tools. In particular, there is no need for the designer to have any 

✓ 

knowledge regarding the internal details of tools employing these intent modeling techniques. 
Rather, the designer is free to focus on characteristics of the design under test. For example, 
according to one embodiment, incorporation of Sentry verification entities into a hardware design 
representation only requires simply annotations indicative of the expected state of variables at 
various points in the control flow structure of a finite state machine associated with the hardware 
design representation. 

[0074] Referring now to Figure 4 A, a high-level block diagram illustrating an exemplary 

Sentry verification entity 400 will now be described. At this level, the Sentry verification entity 400 
may be conceptually thought of as an object that enables explicit association of state information 
with variables of a language description of a hardware design. This association may be 
accomplished by "declaring" a variable, e.g., an interconnect in the hardware design representation 
through with logical signals pass, as a Sentry verification entity resulting in the creation of a sentinel 
variable. Data in 420 represents a flow of data signals into to the sentinel variable (e.g., an 
assignment of a data value to the sentinel variable); and data out 440 represents a flow of data 
signals out of the sentinel variable (e.g., an assignment of the current data value of the sentinel 
variable to another variable in the representation of the hardware design). As described further 
below, one or more control signals 410 may be employed to represent the intended flow of logical 
signals among sentinel variables by associating expected states with the sentinel variables at 
different points of the designs control flow. Additionally, design verification checks, expressed as a 
function of the expected states of the sentinel variables, may be automatically formulated thereby 
allowing the integrity of the data flow to be verified by confirming whether or not any positive 
checks (e.g., checks that indicate a design defect when there is a solution) are violated or whether or 
not a counterexample may be found for any negative checks (e.g., checks that indicate a design 
defect when there is not a solution). 
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[0075] Figure 4B is a schematic diagram illustrating an exemplary implementation of a 

Sentry verification entity 400 according to one embodiment. In the embodiment depicted, the Sentry 
verification entity 400 includes a state latch 445 to store the current state 435 of a variable. The 
Sentry verification entity 400 also includes state maintenance logic 455 for maintaining the state 435 
or updating the state 435 based upon a deactivate control signal 41 1 and an activate signal 412. In 
this example, the state maintenance logic 455 comprises an AND gate 415 and an OR gate 425. The 
AND gate 415 receives the current state 435 of the corresponding variable from the state latch 445 
and an inverted version of the deactivate control signal 411. The OR gate 425 receives the output of 
the AND gate 415 and the activate control signal 412. Consequently, the state maintenance logic 
455 outputs the same state input from the state latch 445 when both the activate control signal 412 
and the deactivate control signal 41 1 are logic 0 thereby holding the variable's current state. The 
state 435 transitions to active, e.g., logic 1, if the activate control signal is logic 1; and the state 435 
transitions to inactive, e.g., logic 0, if the deactivate control signal is logic 1 . In this example, the 
input combination of logic 1 on both the activate control signal 412 and the deactivate control signal 
41 1 is invalid. Importantly, while for simplicity the present example is illustrated with two states, 
active and inactive, the concept of associating state information with a variable in a hardware design 
representation by Sentry verification entities is extensible to more than two states. Also, it is 
appreciated that the implementation of the Sentry verification entity 400 may have many equivalent 
logical representations than that depicted in Figure 4B. The implementation of Figure 4B, 
therefore, is to be considered merely representative of one or the many various possible logically 
equivalent implementations. 

[0076] Figure 4C illustrates what is meant by concept of intended flow of logical signals 

according to one embodiment of the present invention. In one embodiment, if a path (not necessarily 
a "sensitized path") exists between two sentinel variables, then there is a flow of logical signals from 
one to the other. In this example, since the outputs of sentinel variables 401, 402, and 403 are all 
electrically coupled to the input of sentinel variable 405 in the resultant hardware component, design 
verification checks associated with sentinel variable 405 will be a function of at least the state of 
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sentinel variables 401, 402, and 403. Notably, in this example, there is not always a "sensitized 
path" between each of the sentinel variables 401, 402, and 403 and sentinel variable 405 as the 
output of any given sentinel variable 401, 402, and 403 does not always have an effect on the value 
of sentinel variable 405. Consequently, it may be said that a design structure implements the 
intended flow of logical signals between key elements (e.g., sentinel variables) in the design where 
the intended flow of logical signals consists of: (1) The logical signal at a key destination design 
element, at a given time, resulted from the logical signals at a set of key source design elements, at 
the same or earlier time, and would be different or will not change if a key source signal was 
different or did not change respectively; (2) The logical signal at a key destination design element, at 
a given time, independent of the logical signals at a set of key source design elements, at the same or 
earlier time, and will not change if a key source signal was different, (3) The logical signal at a key 
source design element, at a given time, should not govern the logical signal at a key destination 
design element. This intended flow of logical signals can be inferred from the states associated with 
the key variables and the rules for correct design behavior. 

Exemplary Annotations 

[0077] Various statements that may be used to make up annotations will now be described. 

According to one embodiment, annotations can be entered in one of two ways: 

( 1 ) A Single Line // vx statement; 

(2) Multiple Lines /* vjc code ON 

statement; 
statement; 

*/ 

[0078] According to one embodiment, any synthesizeable Verilog can also be entered within 

the context of an annotation to create additional validation checks. Importantly, by placing these 
annotations within the RTL code itself, the designer performs three tasks in one: 
1 . Documents the source code through the assertions 
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2. Identifies assumptions made during block development 

3. Prepares the RTL for validation 

[0079] Several built-in constructs may be used in annotations or semantics of the RTL to 

simplify assertion coding. The examples listed in Table 1 cover common behaviors that many 
signal groups exhibit. In these examples, the syntax for an annotation comprises a comment 
delimiter (e.g., "//" or a "/*" "*/" pair), a directive marker (e.g., "vx"), a directive (e.g., "onehot"), 
and optional directive parameters (e.g., variables i, j, and k). 



Annotation 


Meaning 


// vx onehot (i,j,k); 


Exactly one of i, j, or k must be high 


//vx onecold (i,j,k); 


Exactly one of i, j, or k must be low 


// vx onetrue (ij,k); 


At most one of i J, or k can be high 


//vx onefalse(i,j t k); 


At most one of i, j, or k can be low 



Table 1: Built-in Assertions 



[0080] Such assertions allow the designer to explicitly specify design constraints for 

annotated signals. According to one embodiment, techniques are also provided for implicit design 
constraints based upon the control flow in the circuit. These implicit constraints are thought to be 
key to both block and interface validation. 

[0081] In any design, signals are used to coordinate information exchange between different 

sections of the circuit. Such signals may be the contents of a data bus, or the handshaking signals 
between two interacting state machines. These key signals are referred to herein as sentinel 
variables of the design. The purpose of other logic in the circuit is to ensure proper interaction 
between these signals. A design failure is nothing but the incorrect exchange of data among sentinel 
variables. 

[0082] According to one embodiment, sentinel variables are identified in annotations by the 

"sentry" directive. Sentry verification entities may be used to identify a sentinel signal and to model 
its behavior. In the examples described herein, Sentry verification entities have two states, active 
and inactive, that are controlled by "activate" and "deactivate" directives presented in vx 
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annotations. The various Sentry verification entity controls, e.g., in the form of annotations, are 
placed in the control flow of the design so that the state of the Sentry verification entity is dependent 
on the state of the design. The Sentry verification entity should be activated when its corresponding 
sentinel variable carries valid information that is utilized somewhere in the design, and deactivated 
when the data is invalid or not used. Importantly, according to one embodiment, ID V automatically 
validates multiple forms of data exchange between sentinel variables to ensure that the exchange is 
always valid. This checking mechanism works both in block-level and full-chip validation. 
[0083] According to one embodiment, the designer is responsible for identifying signals that 

should be modeled as Sentry verification entities. Common sentinel variables in a design are: 
handshaking signals, data buses, state variables, and output ports. After sentinel variables have been 
identified, the designer may add appropriate annotations to the design representation. 
[0084] Any signal (wire, register, or I/O) may be declared as a Sentry verification entity. A 

Sentry verification entity may also be declared on a sub-range of a vector. Each Sentry verification 
entity declaration should also identify a clock signal that controls when the corresponding sentinel 
variable may change its value. The following are examples of sentry annotations: 
reg a; // vx sentry a: elk- 

wire b; // vx sentry b: elk; 

reg [0:15] c; //vx sentry [1:2] c: elk; 

[0085] According to one embodiment, Sentry verification entities alternate between active 

and inactive states based upon the control flow in the design. For instance, a data bus controlled by 
a state machine may be declared as a Sentry verification entity. When the state machine is in the idle 
state, the data bus Sentry verification entity is deactivated. Once the state machine enters a 
transmitting state, the data bus Sentry verification entity is activated. Any other Sentry verification 
entities in the design that try to access the data bus while it is deactivated will be flagged as an error, 
such as a "bad data access" error. Similarly, a design defect is indicated if no other Sentry 
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verification entities in the design are accessing the data bus while it is active. For example, a "data 
loss" may be reported. 

[0086] According to one embodiment, Sentry verification entities may be activated and 

deactivated using the annotations in Table 2. 



Annotation 


Meaning 


//vx activate (a); 


Activate Sentry a: 


//vx deactivate(a); 


Deactivate Sentry a: 



Table 2: Exemplary Sentry verification entity controls 



[0087] Sentry annotations may be placed within the control flow of the design so that the 

state of the Sentry verification entity is dependent on the control state. Sentry annotations can also 
be coded using the "//vx code on" annotation thereby allowing the designer to code the Sentry 
verification entity states within their own annotation block separate from the source code for the 
hardware design representation. 

Formulation of Design Verification Checks 

[0088] Figure 5 is a flow diagram that illustrates the automatic formulation of design 

verification checks according to one embodiment of the present invention. As described above, 
properties may be verified by breaking them down into one or more checks and performing 
verification processing at the check-level. Briefly, according to this example, a set of predetermined 
properties are applied to each sentinel variable in the design representation. More specifically, the 
predetermined properties are applied to signal propagation among the sentinel variables to produce 
an exhaustive list of checks that confirm whether or not the predetermined properties are violated for 
the intended flow of logical signals. 

[0089] According to the embodiment depicted, design verification check formulation begins 

at processing block 510 where a model of the hardware design under test is received. Preferably, the 
model includes embedded objects, such as Sentry verification entities, associated with each sentinel 
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variable to facilitate check generation. At processing block 520, the model is traversed to locate the 
next sentinel variable. Upon locating the next sentinel variable, at processing block 530, design 
verification checks for the sentinel variable are automatically formulated based upon the 
predetermined properties. For example, each property may be expressed as one or more checks. 
Further, many of the checks may be expressed at least partially as a function of the states of one or 
more sentinel variables as described further below. 

[00901 At processing block 540, a determination is made whether or not the model traversal 

is complete. If so, processing proceeds to processing block 550. Otherwise, processing returns to 
processing block 520. At processing block 550, the design verification checks generated in 
processing block 530 are added to the property manager for subsequent linking and analysis, for 
example, which are described further below. 

Exemplary Properties / Design Verification Checks 

[0091] Empirical analysis performed by the assignee has shown that verification of a 

relatively small set of properties at key points of a hardware design representation (e.g., handshaking 
signals, data buses, state variables, and output ports) can guarantee the absence of errors in the 
hardware design with a high level of confidence. 

[0092] An exemplary set of properties will now be described. Importantly, however, the 

present invention should not be construed as being limited to this particular set of properties or the 
use of sentries. In various circumstances, a subset of the properties described below may be 
sufficient to achieve the desired level of confidence. Additionally, the set of properties described 
herein is not intended to be an exhaustive list. It is contemplated that Sentry verification entities and 
the verification techniques described herein would be equally useful in the context of a larger set of 
properties or even a completely different set of properties. 

[0093] In one embodiment, the predefined set of properties applied to signal propagation 

among the sentinel variables of the hardware design representation include: access of invalid data 
(AID), loss of valid data (LVD), assertion correctness (AC), conflicting assignments (CA), block 
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enable (BE), assignment execution (AX), constant value memory element (CME), constant value 
variable (CV), Sentry activate always off (AAO). 

[0094] AID (Access of Invalid Data) is an undesirable condition. A Sentry verification 

entity that is in the valid state should not receive data that flowed through a Sentry verification entity 
that was in the invalid state. Therefore, a solution to one or more checks representing a violation of 
this property is indicative of a design defect. According to an embodiment of the present invention, 
an approach for finding AID is to search for an input sequence for the sentinel variable under 
verification, starting from the reset state, that will: (1) set the corresponding destination Sentry 
verification entity in the valid state, (2) create a sequentially sensitized path from a source Sentry 
verification entity to the Sentry verification entity under verification, and (3) set the source Sentry 
verification entity in the invalid state at the time when the sensitive data was flowing through the 
destination Sentry verification entity. 

[0095] LVD (Loss of Valid Data) is another undesirable condition. Any data flowing 

through a Sentry verification entity that is in the valid state must be received by some Sentry 
verification entity that is in the valid state. Therefore, a solution to one or more checks representing 
a violation of this property is indicative of a design defect. According to an embodiment of the 
present invention, an approach for finding LVD is to search for an input sequence for the sentinel 
variable under verification, starting from the reset state, that will: (1) set the corresponding source 
Sentry verification entity in the valid state, and (2a) block the sensitized paths between the source 
Sentry verification entity and all possible destination Sentry verification entities, or (2b) set the 
destination Sentry verification entities with sensitized paths from the source Sentry verification 
entity, in the invalid state. 

[0096] AC (Assertion Correctness) is a desired condition. An assertion represents a 

condition the designer explicitly indicated should occur at a particular point in the design. 
Consequently, a counterexample for compliance with the assertion is indicative of a design defect. 
According to an embodiment of the present invention, an approach for determining an AC violation 
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is to search for an input sequence for the sentinel variable under verification, starting from the reset 
state, that will be a counterexample for the assertion. 

[0097] The remaining properties (i.e., conflicting assignments, block enable, assignment 

execution, constant value memory element, constant value variable, and Sentry activate always off) 
may be verified in a similar manner. However, for sake of brevity, checking algorithms for these 
properties will not be described. Rather, only brief descriptions will be provided. CA (Conflicting 
Assignments) is an undesirable condition where a wire in the design can be driven by multiple 
conflicting drivers. BE (Block Enable) checks if the condition enabling the execution of a certain 
block of code in the HDL will never be enabled. AX (Assignment Execution) checks to see if each 
logical value can be assigned to a variable through each assignment. CME (Constant Value Memory 
Element) checks to see if a memory element in the design will always hold a constant value. CV 
(Constant Value Variable) checks to see if a variable in the design will always hold a constant value. 
AAO (Sentry Activate Always Off) is an undesirable condition indicative of an error in the 
specification of the design intent where a sentry verification entity is never set in active state. 

An Exemplary Design Example 

[0098] In the design example illustrated by Figures 6 - 9, it is assumed that there is a need 

for three independent units, such as microprocessors, client A 605, client B 610, and client C 615, 
that are required to share access to the same memory 640, such as a synchronous RAM. In this 
design example, it is assumed that the memory 640 requires a single read/write signal. The 
following data/control signals are therefore needed from each unit: (1) Address - 10 bits, (2) Write 
data - 8 bits, (3) Read data - 8 bits, and (4) Read/write - 1 bit. As a result, an arbiter, such as round 
robin arbiter 636, has been designed that accepts data from each unit 605, 610, and 615 and 
arbitrates to determine which one is granted access to the memory 640 at any one time. Each unit 
605, 610, and 615 will initiate a memory request signal when it wants access to the memory 640 and 
will deactivate it when finished. If more than one unit 605, 610, and 615 requests the bus 641 at the 
same time, access should be grated on a "round-robin" basis so that no one unit 605, 610, or 615 is 
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locked out while another has continuous access. Continuous access is granted to any one unit 605, 
610, or 615 for a period of time, up to a number of clock cycles separately programmable from client 
A's data bus 606. When a programmable "watch dog" time has not been set, an 8 clock cycle delay 
should default. For speed purposes, the use of Tri-state buffers, rather than multiplexers is desirable. 
[0099] Figure 6B is a block diagram illustrating the design example of Figure 6A with the 

inclusion of Sentry verification entities at appropriate points of the circuit corresponding to the RTL 
representation of Figures 9A - 9E. Thus, Figure 6B conceptually illustrates the internal model 
representation after the model builder 145 embeds Sentry verification entities 645, 650, 655, 660, 
665, and 670; and as seen by the design intent analyzer 140 and the analysis engine 180. 
[00100] In this example, the Sentry verification entities 645, 650, 655, 660, 665, and 670 have 
been chosen to (1) verify the operation of the signals between clients 605, 610, and 615 and bus 
interface units (BIUs) 620, 625, and 630, respectively; and (2) verify the operation of the signals 
between the BIUs 620, 625, 630 and the round robin arbiter 635. The data signals (i.e., dataA, 
dataB, and dataC) flowing from clients 605, 610, and 615 to bus interface units (BIUs) 620, 625, and 
630, respectively, are declared as sentinel variables at line 20 of Figure 9A. The data signals (i.e., 
dataOut ) flowing from BIUs 620, 625, and 630 to clients 605, 610, and 615, respectively, are 
declared as sentinel variables at line 50 of Figure 9B. The data signals (i.e., dataA, dataB, and 
dataC) received by the round robin arbiter 635 are declared as sentinel variables at line 1 15 of 
Figure 9C. 

[00101] The states associated with the Sentry verification entities 645, 650, 655, 660, 665, and 
670 at different points of the control flow are controlled by way of annotations at line 21 of Figure 
9A, at lines 73, 81, and 91 of Figure 9B, at line 131 of Figure 9C, and at lines 156, 169, and 180 of 
Figure 9D. In this example, therefore, the designer has expressed his/her intent that (1) the Sentry 
verification entities associated with dataA, dataB, and dataC remain active constantly in module 
main; (2) on reset, the Sentry verification entity associated with dataOut is deactive; (3) the Sentry 
verification entity associated with dataOut is deactive when the corresponding BIU is in the 
"NO_REQ" state and active when the corresponding BIU is in the "GRANTED" state; (4) the 
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Sentry verification entities associated with dataA, dataB, and dataC are deactive during state 
transition of the round robin arbiter 635; and (5) the Sentry verification entities associated with 
dataA, dataB, and dataC are activated when the round robin arbiter is in "stateA", "stateB", and 
"stateC", respectively, thereby allowing only one of dataA, dataB, and dataC to be active at any 
given time. 

[00102] An exemplary text report file illustrating the verification results for the annotated 
RTL of Figures 9 A - 9E will be described below with reference to Figures 13 A - 13E. 

Linking 

[00103] As mentioned above, the property manager 1 65 may track information regarding 
relationships among the various design verification checks generated by the design intent analyzer. 
In the embodiments described herein, the linking process is performed concurrently with verification 
of the checks. In alternative embodiments, however, linking and verification processing may be 
performed separately. In any event, the dependency relationships (or "linking" information) may be 
used to facilitate error reporting or used to streamline check verification processing. 
[00104] Figure 10 is a block diagram that conceptually illustrates linking processing 
according to one embodiment of the present invention. According to this example, link processing 
involves both the property manager 165 and the analysis engine 180. The property manager 165 
provides the next check 1005 to be processed to the analysis engine 180; and the analysis engine 180 
returns link information 1010, such as whether or not the currently processed check is dependent 
upon another check and if so, which check. The analysis engine 180 includes a linking process 1020 
and a local model 1025. The local model 1025 is initialized with a copy of the model 1015 
generated by the model builder. However, during link processing, the local model is modified to 
disable various checks. 

[00105] Figure 11 is a high-level flow diagram that illustrates linking processing according to 
one embodiment of the present invention. At processing block 1 1 10, the next design verification 
check is received by the analysis engine 180 from the property manager 165. In order to avoid 
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circular dependency relationships, those design verification checks that are already known to be 
dependent upon the received design verification check are disabled in the local model 1025 at 
processing block 1 120. The received design verification check is evaluated at processing block 1 130 
and appropriate linking is also performed. Then, at processing block 1 140, all of the design 
verification checks are enabled in anticipation of further check processing. Finally, at decision block 
1 1 50, a determination is made whether or not there are more checks to be processed. If so, control 
flow returns to processing block 1110. Otherwise, link processing is complete. 
[00106] Figure 12 is a flow diagram that illustrates processing block 1 130 of Figure 11 
according to one embodiment of the present invention. Processing of the received design 
verification check begins at processing block 1231 where the previous partial solution is expanded to 
create a current partial solution. Next, at processing block 1232, the current partial solution is 
evaluated; and a determination is made at processing block 1233 whether or not the current partial 
solution violates an independent check. If it is determined that the current partial solution violates 
an independent check, then processing proceeds to processing block 1235. Otherwise, processing 
branches to decision block 1234. 

[00107] At decision block 1234 the current partial solution is tested to determine whether or 
not it is complete. If the current partial solution is complete, then the currently processed check is 
marked as an independent check and processing continues with processing block 1238. Otherwise, 
if the current partial solution is not complete, then processing returns to processing block 123 1 . 
[00108] Assuming the current partial solution has been found to violate an independent check, 
then at processing block 1235, the current check is temporarily locally marked as being dependent 
upon the independent check. At processing block, a determination is made whether or not the 
current partial solution can be rectified to remove the violation of the independent check. If the 
current partial solution can be so rectified, then processing proceeds to processing block 1237. 
Otherwise, processing continues with processing block 1238. At processing block 1237, the current 
solution is rectified to remove the violation and control flow returns to processing block 1231. 
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[00109] Finally, at processing block 1238, the local dependency information is used to update 
the master dependency information in the property database 160. In this manner, an intent violation 
hierarchy may be built for use during reporting of design defects. 

Intent Violation Reporting 

[001101 Figures 13A - 13E illustrate an exemplary text report file for the annotated RTL of 
Figures 9A - 9E according to one embodiment of the present invention. In this example, a summary 
of the functional checks is listed at lines 5 through 17. The summary indicates a total of five failed 
checks, three inconclusive checks, twelve interface checks, and 144 passed checks (some of which 
may be conditional). A summary of the failed checks is listed at lines 27 through 38. One block 
enable violation is reported at line 31, one assignment execution violation is reported at line 32, and 
three occurrences of loss of valid data are reported at line 38 of Figure 13 A. Exemplary detailed 
debugging information regarding the property violations is shown in Figure 13B. 
[00111] In the foregoing specification, the invention has been described with reference to 
specific embodiments thereof. It will, however, be evident that various modifications and changes 
may be made thereto without departing from the broader spirit and scope of the invention. The 
specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive 
sense. 
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